## Context
@posthog/dags/flag_evaluations_parity.py#L63-82

<issue_description>
`day` comes from the wall clock when the op starts. A delayed run after midnight checks the wrong day. Operators also cannot rerun an alert's date.
</issue_description>

<issue_validation>
- **Checked:** `_target_day` and its single call site, the schedule definition, the Dagster scheduler in the installed venv, and how other daily jobs in this repo derive their day.
- **Found:** `posthog/dags/flag_evaluations_parity.py:63-64` reads the wall clock, and line 82 binds it once per op execution. The op accepts no day. `FlagEvaluationsParityConfig` (lines 19-44) exposes `enabled_team_lookback_days`, `teams_per_query`, and `max_teams` only, so a run cannot be pointed at a chosen date. The schedule at lines 236-242 passes no run config.
- **Found:** replayed ticks are a real mechanism, not a hypothesis. The installed Dagster launches runs for missed ticks up to `DEFAULT_MAX_CATCHUP_RUNS = 5` (`.venv/lib/python3.13/site-packages/dagster/_core/scheduler/scheduler.py:211`, applied in `_scheduler/scheduler.py`). A schedule that falls behind — a paused schedule, a daemon outage, an unavailable code location — resumes and submits runs for past ticks. Each of those runs computes `now() - 1 day` and checks yesterday, so the missed days are never checked and several runs repeat the same day.
- **Found:** this repo already solves the same problem the way the suggestion describes, and records the reason. `products/signals/dags/inbox_ranking/dataset/dag.py:937-939` states: "Derived from the tick rather than wall-clock now() so a delayed or replayed tick still builds the partition it was scheduled for." `products/revenue_analytics/dags/exchange_rate.py:322` and `products/signals/dags/inbox_ranking/training/dag.py:466` use the same `context.scheduled_execution_time.date() - timedelta(days=1)` form. The pattern is therefore idiomatic here, not an added abstraction.
- **Impact:** after a schedule outage the job reports successful runs that cover a day it already covered, so gap days go unverified while the coverage looks complete. An operator who reads a deficit alert for a named date also cannot re-run that date, and must write the query by hand — the manual step this job exists to replace.
</issue_validation>

## Task
Investigate the issue and solve it

<potential_solution>
Add a `target_day` config field. Have the schedule set it from `context.scheduled_execution_time`. Use yesterday only when no value exists.
</potential_solution>

## Context
@posthog/dags/flag_evaluations_parity.py#L89-101

<issue_description>
The query discovers a team only after `flag_evaluations` accepts a row. A total outage for a newly enabled team leaves that team outside `ranked_teams`. The run then reports clean parity. Historical rows also keep disabled teams in the enabled set until the lookback expires.
</issue_description>

<issue_validation>
- **Checked:** the enabled-team query, the lookback config, the no-alert path, the fork's gate, and where the allowlist actually lives.
- **Found:** the discovery signal and the monitored signal are the same. `posthog/dags/flag_evaluations_parity.py:89-101` builds `ranked_teams` only from teams that already have a `flag_evaluations` row in the window. A team whose rows never land — the topic cleared, the lane's mode off, or loss downstream from the first row — never enters the list, so `parity_alert_lines` returns `None` (lines 175-176), the op logs "Parity holds" (line 214), and nothing is posted. Silence is exactly the signal an operator reads as a pass when gating a team.
- **Found:** the reverse half produces false alerts, and its trigger is a designed operation. The window keeps a team for `enabled_team_lookback_days` (default 7, lines 22-29, 97). After a team leaves the allowlist, it still has rows in the window, so the comparison runs for a day where the fork wrote nothing while `$feature_flag_called` events still land. Every one of those events counts as `only_in_events`, and any non-zero deficit alerts (lines 170-176). The alert then fires at full day size, each day, for a week.
- **Found:** disablement is an operational action, not a hypothesis. `nodejs/src/ingestion/common/flag-evaluations/flag-evaluations-service.ts:14-16` documents `excludedTeams` as an "Escape hatch: teams never forked", and lines 29-33 describe shedding the fork during an incident by clearing the mode and the topic. Shedding the fork therefore starts a week of maximum-size deficit alerts right after an incident.
- **Found:** the suggested remedy is a cross-system change, not an edit to this file. The allowlist is deployment env config read by the Node ingestion service — `INGESTION_FLAG_EVALUATIONS_TEAMS`, `INGESTION_FLAG_EVALUATIONS_EXCLUDED_TEAMS`, and `INGESTION_FLAG_EVALUATIONS_MODE` (`nodejs/src/ingestion/config.ts:247-249`, `flag-evaluations-service.ts:47-54`). No queryable store holds it, so a shared source has to be built first.
- **Impact:** the monitor cannot see the worst case it exists to catch, a team that loses every row, and it raises loud false deficits for a week after any deliberate disablement.
- **Priority:** lowered to `should_fix`. Both effects are confirmed, but they degrade an internal monitor rather than break production, lose data, or change a contract, and closing the blind spot needs an enablement source that does not exist in queryable form today.
</issue_validation>

## Task
Investigate the issue and solve it

<potential_solution>
Read current enablement and activation time from a source that does not depend on successful target writes. Share this source with ingestion. Use table rows only for ranking or validation.
</potential_solution>

## Context
@posthog/dags/flag_evaluations_parity.py#L125-128

<issue_description>
`createFlagEvaluationsService` enables the fork only for real-time lanes. This query reads events from all lanes. An event from the `historical` or `async` lane can therefore create a false deficit.
</issue_description>

<issue_validation>
- **Checked:** the fork's lane gate, the lane sets, the events-side predicate in the parity query, the capture rerouting rule and its threshold, and the `$feature_flag_called` dedup service that reasons about the same lanes.
- **Found:** the premise is exact. `FLAG_EVALUATIONS_ALLOWED_LANES` is `[...REALTIME_INGESTION_LANES, null]` (`nodejs/src/ingestion/common/flag-evaluations/flag-evaluations-service.ts:66`), and `createFlagEvaluationsService` returns `undefined` for any other lane (lines 88-92). The delayed lanes are `historical` and `async` (`nodejs/src/ingestion/config.ts:88`). `overflow` is a real-time lane, so it does fork.
- **Found:** the events side applies no matching restriction. `posthog/dags/flag_evaluations_parity.py:125-128` selects every `events` row for the day with `event = '$feature_flag_called'`. A row from a delayed lane therefore lands in `only_in_events`, and any non-zero deficit alerts (lines 170-176), so one such event is enough to fire.
- **Found:** `$feature_flag_called` really does traverse delayed lanes in this system. `nodejs/src/ingestion/common/feature-flag-called-dedup/feature-flag-called-dedup-service.ts:160-171` excludes the same two lanes for this event type, with the reason that "a backfilled event is not a duplicate of the live event that claimed its tuple an hour ago".
- **Found:** a concrete timing window exists at the normal cadence. Capture reroutes when the event is older than `historical_rerouting_threshold_days`, default 1 (`rust/capture/src/config.rs:280-281`). The job compares day D at 04:00 on D+1, so the reachable age is at most 28 hours. Events timestamped in the first hours of D that arrive more than 24 hours late satisfy both, take the historical lane, are never forked, and count as deficits.
- **Found:** two limits on how often this bites, which I could not resolve from this repo. `enable_historical_rerouting` defaults to `false` (`rust/capture/src/config.rs:277-278`) and the production value lives in deployment config, and the `async` lane's routing rule is not defined here. Explicit batch imports are not a source at this cadence, because `validate-historical-migration.ts:30` requires an age of at least 48 hours, beyond the 28-hour reach.
- **Impact:** the comparison counts events the fork was never going to write, so a deficit alert can name a team whose fork is working. With no threshold on the deficit, a low but steady rate of late events produces a recurring false alarm, which is the outcome the excess rule was written to avoid.
</issue_validation>

## Task
Investigate the issue and solve it

<potential_solution>
Carry a fork-eligible or ingestion-lane marker into events and filter on it. Alternatively, compare against a source that only real-time lanes produce.
</potential_solution>